-
Notifications
You must be signed in to change notification settings - Fork 329
FIX: Incorrect HID Stick values for LogicalMinimum with negative values #2246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
Also creates a simple layout struct for a device with only a single analog stick where the HID report descriptor states that the x and y values are between -127 and 127.
|
||
[StructLayout(LayoutKind.Explicit)] | ||
struct SimpleJoystickLayout : IInputStateTypeInfo | ||
struct SimpleJoystickLayoutWithStickUshort : IInputStateTypeInfo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to create a test with a report descriptor that fits this struct as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR fixes incorrect handling of HID stick values when LogicalMinimum contains negative values by properly implementing 2's complement parsing and sign handling.
- Corrects data parsing to handle signed byte and short values using proper casting
- Fixes a bit shift error in 32-bit integer parsing
- Updates stick control format determination to use a proper method instead of simple boolean check
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
File | Description |
---|---|
HIDParser.cs | Fixes signed value parsing with proper casting and corrects bit shift error |
HID.cs | Updates stick format determination and adds debug logging |
HIDTests.cs | Adds comprehensive test for signed logical min/max values and refactors test helpers |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Co-authored-by: Copilot <[email protected]>
|
||
builder.AddControl(stickName + "/y") | ||
.WithFormat(yElement.isSigned ? InputStateBlock.FormatSBit : InputStateBlock.FormatBit) | ||
.WithFormat(yElement.DetermineFormat()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change was included from #2245
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it required to always determine format for any control? Also buttons support this (but I cannot recall ever seeing it in practise), but definitely e.g. triggers go into same territory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, and we also did it before. Not sure why assigned it the SBit/Bit format before but we do read multiple "bits" if we had them (e.g. in stateBlock.ReadFloat()). So it might have been to deal with cases where we could use like "10 bits" to define an axis. I'll have a look and test this as well to see if there are any other changes needed. Thanks.
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## develop #2246 +/- ##
===========================================
+ Coverage 68.14% 76.72% +8.58%
===========================================
Files 367 465 +98
Lines 53685 87947 +34262
===========================================
+ Hits 36584 67479 +30895
- Misses 17101 20468 +3367 Flags with carried forward coverage won't be shown. Click here to find out more.
... and 102 files with indirect coverage changes 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into this. I am confused about our ReadData method, it is not yet clear to me how we handle sign-extended types of arbitrary bit sizes? E.g.
It's completely valid to have e.g. X with logical min -15 logical max 16, and hence Report size 5
|
||
builder.AddControl(stickName + "/y") | ||
.WithFormat(yElement.isSigned ? InputStateBlock.FormatSBit : InputStateBlock.FormatBit) | ||
.WithFormat(yElement.DetermineFormat()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it required to always determine format for any control? Also buttons support this (but I cannot recall ever seeing it in practise), but definitely e.g. triggers go into same territory
Description
This PR addresses the issues encountered when parsing data for devices that have LogicalMinimum values with negative values. Seems we weren't taking 2's complement values into account.
Also includes fixes from user PR #2245
Testing status & QA
Tested with a Gamepad stick which has both signed short and byte for LogicalMin/Max of [-127,127] and [-32.768,32.767]
Overall Product Risks
Comments to reviewers
This is not easy to test without real devices that we don't have a layout for so I at least hope existing devices would still work.
One strategy could be to test this on macOS and comment this line:
InputSystem/Packages/com.unity.inputsystem/InputSystem/InputSystem.cs
Line 3798 in d1d72d5
Then look if the sticks were well interpreted.
However, this only allows us to verify for devices that send Stick values as a signed short. For signed bytes I don't know of a device besides the ones users have reported in Discussions https://discussions.unity.com/t/input-system-reading-invalid-values-from-hall-effect-keyboards/1684840/3
Checklist
Before review:
Changed
,Fixed
,Added
sections.Area_CanDoX
,Area_CanDoX_EvenIfYIsTheCase
,Area_WhenIDoX_AndYHappens_ThisIsTheResult
.During merge:
NEW: ___
.FIX: ___
.DOCS: ___
.CHANGE: ___
.RELEASE: 1.1.0-preview.3
.After merge: